home *** CD-ROM | disk | FTP | other *** search
- Path: keats.ugrad.cs.ubc.ca!not-for-mail
- From: c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku)
- Newsgroups: comp.lang.eiffel,comp.lang.c,comp.lang.c++,comp.object,comp.software-eng
- Subject: Re: Beware of "C" Hackers -- A rebuttal to Bertrand Meyer
- Date: 24 Mar 1996 07:20:32 -0800
- Organization: Computer Science, University of B.C., Vancouver, B.C., Canada
- Message-ID: <4j3p80INN567@keats.ugrad.cs.ubc.ca>
- References: <1995Jul3.034108.4193@rcmcon.com> <31545B86.4CC0@iadfw.net> <4j26cn$gh7@solutions.solon.com> <3154A548.71FF@iadfw.net>
- NNTP-Posting-Host: keats.ugrad.cs.ubc.ca
-
- In article <3154A548.71FF@iadfw.net>, Larry Weiss <lfw@iadfw.net> wrote:
-
- >OK, now we are in sync. I just wanted to know if anyone who used to
- >do that sort of thing was upset with the implementations that choose to
- >use inline techniques at code generation time for one or more standard
- >library functions.
-
- I would be very upset if the implementation did not allow me to turn it of,
- like the -fno-builtin option of GCC. Sometimes it is very useful to write your
- own malloc() (though I don't know of any implementation that inlines malloc()
- calls).
-
- >Looking at it another way, until the C Standard was published, I just looked
- >at the vendor supplied library as a popular example of how one might go about
- >interfacing with a file system, or manipluating strings, etc. I didn't
- >think of the library as a formal part of the C language. Now, of course
-
- Neither does the K&R2: this I think is a major flaw in the otherwise great
- book. It never makes clear the concept that the standard library is a component
- of the language. In fact, it claims the opposite:
-
- The standard library is not part of the C language proper, but an
- environment that supports standard C will provide the function
- declarations and type and macro definitions of this library.
- (beginning of Appendix B).
-
- >the standard library is a well defined component of the C language, with
- >the implementation able to know all sorts of things about the semantics of
- >each library function. C suddenly became much larger and complex with the
- >publication of the Standard, in my mind. It would have been nice if the
-
- Not at all; that's the beauty of it! All of the standard library functions can
- be implemented by essentially adding a compatible library and headers to a
- ``freestanding'' implementation. The standard doesn't _require_ that you inline
- any of the functions or that the compiler be aware of special semantics, but
- the implementor has the freedom to do this. This is why the inclusion of
- appropriate headers is still required when you use standard functions---for
- example, you must include <stdlib.h> to call malloc(), or <stdio.h> to use
- printf(). If the compiler were really required to know malloc or printf a
- priori, the need for a header file could easily have been dropped long ago.
- --
-
-